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Abstract Title 
Call centre 



(57) A call center has a number of workgroups (WG1,2,3) each with a routing controller (15) for determining 
the most suitable destination within the workgroup for receiving a call. This determination is done on the basis 
of a routing table periodically generated for the workgroup by the routing controller (15). The workgroups 
exchange their routing tables. The routing controller ( 1 5) of every workgroup thus has sufficient mfonnation to 
globally detennine the most suitable workgroup to handle an incoming call. This redundancy avoids the need 
to provide a fault tolerant central controller. 
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At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 

This print takes account of replacement documents submitted after the date of filing to enable the application to comply 
with the formal requirements of the Patents Rules 1995 
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CALL CENTER 



Field of the Invention 

The present invention relates to call centers logically composed of a number of 
workgroups. In particular, but not exclusively, the present invention relates to call centers 
capable of handling both traditional telephone caUs and VoIP C'Voice over IP") calls. 



Summary of the Invention 

10 According to the present invention, there is provided a call center system with multiple 
workgroups, each workgroup having a routing controller comprising: 

routing-data generating means operative to derive workgroup routing data 
indicative of the suitability of destmations within the workgroup for receiving 
calls; 

1 5 - transfer means for passing the workgroup routing data directly or indirectly to 
the routing controllers of the other workgroups; 
storage means for storing tiie workgroup routing data of all operative 
workgroups, and 
— global routing means arranged to: 
20 - receive a routing request in respect of a call incoming to the call center, 

determine from the stored routing data for all operative workgroups 

which workgroup is most suited to handle a call, and 
- respond to the routing request accordingly. 

25 Rrief Description of th e Drawings 

A call center embodying the invention will now be described, by way of non-limiting 
example, with reference to the accompanying diagrammatic drawings, in which: 
. Figure 1 is a diagram of the call center showing its relation to a PSTN and an IP- 
based network; 

30 . Figure 2 is a diagram similar to Figure 1 showing message paths and call routing 
during connection of a PSTN-originating call to a call-center agent; and 
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. Figure 3 is a diagram similar to Figure 1 showing message paths and call routing 
during connection of a networic-originating VoIP call to a call-center agent. 



5 • Best Mode of Carrying Out the Invention 

The Figure I call center comprises three logical work groups WGl, WG2, WG3 
(generically referred to below as "WG") that may be co-located or geographically 
dispersed. The call center interfaces both with a traditional telephone network 10, and 
with an inter-connected network 20 of IP-based networks (this network of networks 
1 0 being hereinafter referred to sunply as the "IP networic" 20). By way of example, the 
tel^hone network 10 is here shown as a PSTN (analog and/or ISDN based), but may 
equally be a PLMN, a private networic, or similar telephone networic. The IP network 
20 maybe the Internet, an intranet, or similar IP-based network. 

15 The PSTN includes as well as normal switches (not shown), a service switching point 
(SSP) 22 capable of determining that a particular service is required for a call and for 
sending a service request to the service control subsystem of the PSTN. In flie present 
example, the service control subsystem comprises a "WebSCP" 23, namely a service 
control point (SCP) with a web interface for retrieving service data and logic over the 

20 IP network 20 using the web HTTP protocol . Further details of WebSCP 23 are given 
in our published International Application WO97/22210 which is incorporated herein 
by reference. In fact, any SCP with an interface to the IP networic 20 may be used for 
component 23. Whatever the precise form of SCP 23, the SCP wiU respond to a service 
request fix)m SSP 22 with a number to be used for routing the call in respect of which 

25 the service request was made. As will be explained hereinafter, in the present case the 
SCP23 determines its response in dependence on data it receives back from a query 
sent out over the P network 20. 

Each workgroup WG comprises a LAN 1 1 to which are connected a pluraUty of agent 
30 workstations 12, a media gateway 13, a media server 14, a gatekeeper 1 5 with an 
associated web server 16, and a router 17. Each workgroup WG connects via its 
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gateway 13 to the PSTN 10, and via its router 17 to the IP network 20 of which it 
substantially forms a part. 

Each woikgroup can thus receive calls fiom both the PSTN and fiom terminals 21 
(such as a PC) linked to the IP network 20. Calls from the PSTN are received at the 
gateway 13 and are converted into a VoIP call for routing to a selected agent 
workstation^ over LAN 10. VoIP calls from terminals 21 are received at the router 17. 

By way of example, the VoIP caUs wiU be taken to be in accordance with the H.323 
standard though other VoIP standards can alternatively be used. 

Each agent workstation 12 is capable of handling Voff calls and. in addition, can 
receive caller data for screen display to the agent. This caller data can be derived fiom 
any appropriate source such as a caller database (not shown) holding known 
information about a caller, or fiom an infoimation-coUecting resource arranged to 
gather caller data as an initial phase of a current call (for example, using the media 
server or a related website interaction with the caller). 

Calls received at a workgroup WG may instead of being routed to an agent 
workstation, be routed to the media server for delivery of voice announcements (more 
generally for every capability involving data streaming) and/or the collection of user 
input. 

Although each workgroup WG has been described as being composed of elements all 
connecting with the same LAN 10 , it would be possible to remotely locate elements. 
For example, one or more agent workstations may reside at a remote location on a 
different LAN or at the end of an ISDN link. The physical location of the components 
is not itself of importance, but it is necessary for the gatekeeper 15 to know (or be able 
to determine) the IP address of the components of the same workgroup WG. 



Consideration will next be given as to how call control is effected for the call center. At 
a basic level, control of the VoIP calls in the IP network 20 (whether PSTN originating 
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or terminal-originating) is effected in known manner by gatekeepers (eg gatekeepers 
15) that exchange control messages (for example in accordance with the Inter- 
GateKeeper protocol of the H.323 standard). Thus, the gatekeeper 15 of a workgroup 
WG will know the IP addresses of the associated agent workstations 12 and can return 
the IP address of an available agent workstation in response to a request as to where to 
route an incoming call. 

At a higher level, the gatekeeper 1 5 of a workgroup WG also performs a workgroup- 
level control function by determining priorities between its agent resources. More 
particularly, the gatekeeper 15 keeps track of the availability of agents at the agent 
workstations ("availabiUty" being dependent on factors ranging from simple presence, 
to length of call-waiting queue). Additionally, the gatekeeperlS will store poUcies and 
data relating to agent skiU level and time-of day routing. Based on all these factors 
(and potentially further factors), the gatekeeper 15 will constmct a routing table, in a 
manner well understood by persons skilled in the ait. which it stores. This routing table 
is then used by the gatekeeper to detennine to which workstation 12 to allocate a call 
(the caU may not be immediately be routed to that workstation but may need to be 
queued and/or connected to the media server 14 as a preliminary step). The gatekeeper 
15 updates its routing table at frequent intervals (or whenever a relevant parameter 
changes). 

In the present caU center, the gatekeepers 15 of all the workgroups WG are arranged to 
exchange tiieir routing tables at frequent intervals, each gatekeeper 15 storing tiie 
routing tables for all workgroups WG. The exchange of routing tables (indicated by a 
dotted ellipse in Figure I) can be effected either using IGCP (in which case the 
gatekeepers themselves effect the exchange) or using HTTP (in which case it is the web 
servers 16 associated with each gatekeeper 15 that effect the exchange). Any 
distribution topology may be used for the exchange (ring, fully meshed, etc.). 

Since each gatekeeper 15 now has access to the routing tables for all workgroups, each 
gatekeeper can make global routing decisions between the workgroups, that is, decide 
which workgroup is best suited to handle any particular call. The algorithm used to 
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determine which workgroup is best suited should be the same for each gatekeeper to 
ensiu'e consistency of decision between them; how such an algorithm may make its 
selection is well understood by persons skilled in the art and will therefore not be 
detailed. 

5 

Having described the basic structure and control functions of the call center, two 
examples of its operation will now be given. 

Figure 2 illustrates how a call from a PSTN phone 30 is handled. The caller calls a 
10 number N (here given as "0800 123456") that indicates to the SSP 22 that the caller 

wishes to place call (in this example, a fiee-phone call) to the call center. The number N 
may already designate a particular workgroup or it may simply designate tihe call center 
as a whole. The SSP 22 makes a service request to the SCP 23 which, in turn, makes a 
request to one of the HTTP servers 16 of the call-center workgroups asking for the 
15 telephone number to which flie call should be routed. The server 16 contacted may be 
dependent on the number N or may chosen according to some predetermined ordering 
(for example, on a round robin principle). In the present case, it is the server 16 of 
workgroup WGl that is contacted (see thick dashed line 31 in Figure 2). On receiving 
the request, the server 16 passes it to its gatekeeper 15 which then determines from the 
20 routing tables available to it, which workgroup WG is best suited to handle the call (in 
this example, workgroup WG2). The telephone number of this workgroup is then 
returned by the server 16 to the SCP 23 which, in tum, passes it back to the SSP 22. 
SSP 22 then routes the call from phone 30 to the gateway 13 of workgroup WG2 at the 
number passed back to the SSP 22 from the gatekeeper 15 of workgroup WGl . 

25 

The gateway 13 then asks the gatekeeper 15 of workgroup WG2 where it should route 
the call i.e. to which agent workstation 12 or media server 14 (see dashed line 32). The 
gatekeeper 15 responds appropriately and the gateway 13 then passes the call as a VoIP 
call over the LAN 1 1 to the designated agent workstation/media server. 

30 

The route of the call from phone 30 to the agent workstation is indicated by a chain- 
dashed line in Figure 2. 



If during this call set up process. SCP 23 had been unable to obtain a response from the 
server 16 of workgroup WGl, then it will try contacting the server 16 of a different 
workgroup according to a default schedule held by the SCP. If the second choice server 
also fails to respond, the SCP may try a third server 16. This fallback messaging is 
indicated by light dashed lines 33 , 34 in Figure 2. 

This fault tolerant behaviour of the call center is made possible by the fact that the 
routing tables for all the workgroups are available at each workgroup whereby global 
routing decisions can be made by any of the gatekeepers 15. 

Figure 3 shows the handling of a call placed from terminal as a VoIP call (for example 

a "Help Desk" call). In this case, the gatekeeper 40 of the LAN on which the 
terminal 21is situated contacts a gatekeeper 15 of one of the workgroups - in this case 

workgroup WG3 (see dashed line 43). The gatekeeper of workgroup WG3 determines 
from all the workgroup routing tables available to it that the call should be handled by 
workgroup WG2 and informs the gatekeeper 40 accordingly. Gatekeeper 40 then 
contacts the gatekeeper 1 5 of workgroup WG2 (see dashed line 44) asking it for the IP 
address of the agent/media server to which the VoIP call should be routed. Gatekeeper 
15 rehims the IP address of a particular agent workstation 12 in workgroup WG2 and 
gatekeeper 40 passes this information back to terminal 21 . Terminal 21 then estabUshes 
a VoIP call to the appropriate agent workstation (see chain-dashed line). 

It will be appreciated that if the most suitable workgroup was the one first contacted 
(workgroup WG3 in the present example), the gatekeeper of that workgroup will 
directly respond with the IP address of the agent (or other resource) to be contacted. 
Indeed, since the first contacted gatekeeper 15 has available to it the routing table for 
the workgroup determined by it to be the most suitable, it can in theory directly 
determine and return the IP address of the agent/resource to receive the call (assuming 
it had been passed these addresses). However, this is not consistent with the intended 
operation of the gatekeepers which are generally in charge of routing VoIP calls within 
their related domains. Furthermore, it is not necessarily the best strategy to adopt since 
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although the routing tables will be reasonably current, they may not have the very latest 
information concerning agent situation in every workgroup and it will generally be 
better to leave final workgroup-internal routing up to the gatekeeper of the workgroup 
selected. 

5 

With respect to how the gatekeeper 40 determines which gatekeqier 15 to contact 
initially, a number of possibilities exist. Thus, gatekeeper 40 could have previously 
registered with the call center to be informed of the JP addresses of the gatekeepers 15; 
the gatekeeper 15, knowing the addresses of the gatekeepers 15 could then either select 
10 one according to a predetermined policy or broadcast to all gatekeepers 15 (in which 
case, gatekeeper 40 would then utilise only the first response only). 

As with calls placed from the PSTN, calls placed form a terminal 21 benefit from the 
routing information redundancy inherent in the call center whereby should the 
15 contacted gatekeeper 15 be down, the other gatekeepers 15 can be contacted to give the 
same global routing decision. 

Various modifications are, of course, possible to the arrangement described above. For 
example, the SCP 23 rather than talking to the workgroups WG using HTTP, could talk 
20 IGCP directly to the gatekeepers 1 5 ther*y avoiding the need for the servers 1 6. 

Furthermore, rather than the fiiU routing table of each workgroup being passed to the 
other workgroups, a subset of the fiill routing table could be passed giving sufficient 
information to enable the most suitable workgroup to be selected according to the 
selection algorithm in use. 

25 

The network 10, rather than being a telephone network, could, in fact, be any switched 
teleconmiunications network . The network 20 may also be a non IP-based packet 
network. 
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CLABVIS 

1. A call center system with multiple workgroups, each workgroup having a routing 
5 controller comprising: 

— routing-data generating means operative to derive workgroup routing data 
indicative of the suitability of destinations within the workgroup for receiving 
calls; 

transfer means for passing the workgroup routing data directly or indirectly to 
10 the routing controllers of the other workgroups; 

— storage means for storing the woikgroi^ routing data of all operative 

workgroups, and 

— global routing means arranged to: 

-- receive a routing request in respect of a call incoming to the call center, 
15 _ determine fix)m the stored routing data for all operative workgroups 

which woikgroup is most suited to handle a call, and 

— respond to the routing request accordingly. 

— respond to the routing request accordingly. 

20 2. A call center system according to claim 1, wherein at least one of the workgroups is 
adapted to receive calls fix)m the public telephone network and at least one of the 
workgroups is adq}ted to receive calls from a data network as a VoIP call. 



25 3. A call center system according to claim 1 , wherein at least one workgroup is adapted 
to receive calls both from a telephone network, and from a data network as VoIP calls. 

4. A call center according to claim 1 , wherein the workgroup further comprises: 
a LAN to which said routing controller is connected, 
30 - a first interface for interfacing with a data network for receiving VoIP caUs, 

- a second interface for interfacing with a telephone network and for converting 
calls received therefrom into VoIP calls, and 
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agent woricstations for handling calls, 
said routing request being received through said first interface. 
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